Greptile Summary

This PR fixes webhook signature verification to correctly handle Stripe's secret rotation scenario, where multiple v1= entries appear in a single Stripe-Signature header. The previous Object.fromEntries approach silently dropped all but the last v1 value; the new loop collects every value and accepts the request when any one of them matches the computed HMAC.

• index.ts: verifyStripeSignature now iterates over all v1 entries in the header, short-circuiting on the first valid match instead of comparing only a single (potentially stale) signature.
• index.test.ts: A new regression test covers both orderings — valid signature first and valid signature last — ensuring the fix is symmetric and guarding against future regressions.

Confidence Score: 5/5

Safe to merge — the change is a targeted, well-tested fix to header parsing with no regressions introduced.

The new parsing loop is strictly more correct than the replaced Object.fromEntries call: it preserves all v1 values, still uses timingSafeEqual for each comparison, and throws on the same error conditions as before. The test covers both orderings of valid/invalid signatures. No existing behavior is removed or weakened.

No files require special attention.

Important Files Changed

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[Incoming Webhook Request] --> B[Parse Stripe-Signature header]
    B --> C{Split on comma,\ncollect all t= and v1= parts}
    C --> D{timestamp present\nand signatures.length > 0?}
    D -- No --> E[Throw: missing t or v1]
    D -- Yes --> F[Compute expected HMAC\nsha256 over timestamp.rawBody]
    F --> G[Loop over signatures]
    G --> H{actualBuffer.length ==\nexpectedBuffer.length\nAND timingSafeEqual?}
    H -- Yes --> I[Return — webhook accepted]
    H -- No --> J{More signatures?}
    J -- Yes --> G
    J -- No --> K[Throw: Invalid signature]

_{Reviews (2): Last reviewed commit: "test(stripe): cover matching signature l..." | Re-trigger Greptile}